How is the validity of versions 3.2.1 and 4.0 specified?
March 31, 2022 until March 31, 2024
During the transition period, certifications can be made in accordance with PCI DSS v3.2.1 or v4.0. Good to know: Certification according to v3.2.1 is still valid for one year after completion.
From April 1, 2024
Verification according to PCI DSS v3.2.1 is no longer possible as of now. All certifications must now be carried out according to v4.0.
Will the SAQ I have completed in PCI v3.2.1 expire on April 1, 2024?
No, this is not the case. The v3.2.1 attestation, as long as it was completed by March 31, 2024, will remain valid for 12 months beyond that date. Thus, in formal terms only, it would be possible for your company to prove its PCI compliance with v3.2.1 until March 31, 2025.
Are there completely new requirements that must be implemented immediately?
While there are completely new requirements, these are only mandatory to implement after expiry of an implementation period on April 1, 2025. These "Future-Dated Requirements" are considered best practices until March 31, 2025 and remain optional until then. From April 1, 2025, implementing all new requirements of PCI DSS v4.0 will be mandatory.
Is it possible that I did not have to perform ASV scans according to v3.2.1, but according to the new requirements in v4.0 my company is obligated to scan?
Yes, this may indeed be the case.
Even though the classification into SAQ types has not changed with PCI v4.0, there is a significant change with respect to SAQ Type A in terms of performing ASV scans: Version 4.0 adds the requirement to perform ASV scans to the SAQ. The technical reason for this is that the PCI scope of scanning for card payments has been expanded to include the website itself. Thus, the checkout page in the web store that initiates the gateway to the PCI certified service provider for card payments moves into the PCI DSS audit scope.
This has implications for all e-commerce merchants who accept card payments or input of card data via their own website. According to the specifications, the security of the checkout point on the payment page at the merchant's site moves into the PCI audit scope. For e-commerce merchants who allow the entry of card data via their own website, this means that their web stores have to be checked for external vulnerabilities by means of ASV scans every 90 days.
This new requirement was introduced to better protect checkout pages that link to the card payment against attacks by third parties. Using web skimming and insecure payment page scripts, attackers have been increasingly trying to intervene in the processing even before the cardholder is redirected to the pages of the PCI-certified partner.
Are there any price differences for ASV scans according to PCI version 3.2.1 and version 4.0?
No. Pricing is still based on whether you purchase a single scan or an annual package, as well as the number of your scan components for the scan.
What is a payment page?
A payment page is a web form in which the cardholder enters their complete card number (PAN). In terms of e-commerce processing, this refers to the input form in which the cardholder enters their card number when making a payment.
What are payment page scripts?
In PCI v4.0, the term appears in the new requirement 6.4.3, which, as a "Future Dated Requirement", does not have to be implemented until April 1, 2025. The requirement refers to scripts that are integrated on the payment page. These can come from the merchant itself, the payment service provider or from third-party providers. In terms of functions, the scripts may concern, for example, the generation of the iframe in SAQ A as part of the payment. It is also possible that the scripts check the correct entry of card data or are used for advertising purposes, statistics or design. Many more functions are also possible.
What all these scripts have in common is that they can be loaded and/or executed externally on the page and they are therefore a relevant factor for card payment security.
What risk can the use of payment page scripts cause and what approach is there to protect against it?
There is a risk that these seemingly harmless scripts could be used by attackers to upload malicious scripts and use them without being noticed. Malicious scripts could then read and filter out card data from customers' browsers.
To prevent this, it's best to reduce the number of scripts that could be tampered with: ensure that only scripts that are necessary for your payment page to operate and whose relevance you can understand are used.
In addition, ensure that unnecessary scripts are not added to the payment page without proper management approval.
What security measures must be taken regarding payment page scripts?
The security of payment page scripts is applied in requirements 6.4.3 as well as 11.6.1:
Requirement 6.4.3
It is prescribed that only absolutely necessary scripts should be executed on the Payment Page. To ensure secure administration, it is required that scripts are inventoried, authorized, and integrity checked. For each script, a justification for including it on the payment page must be provided.
Requirement 11.6.1
A procedure is required that detects unauthorized changes to the content of the Payment Page and/or the http header at an early stage. To achieve the aim, the check must be carried out periodically. In the event of suspicious circumstances, an automated alert must be sent to the merchant/service provider at the same time.
Where can I learn more about the changes brought about by PCI DSS version 4.0?
Our experts have summarized the changes that PCI DSS v4.0 entails for you in Video and Blog format. We will keep you updated on further developments in our PCI News Blog on our corporate website.